This is the codepath used by Report() / ReportAt(), which is the fast path for
reporting stats in v4. Skipping the sort saves us some work:

    benchmark                              old ns/op     new ns/op     delta
    BenchmarkTagsBufferSortSorted-12       107           49.3          -53.93%
    BenchmarkTagsBufferSortUnsorted-12     270           271           +0.37%

While users are less likely to have already-sorted stat tags in this case
(because the tagsBuffer tag slice is built on every call and doesn't retain its
sort between calls the way that you would retain sorted engine tags if you were
calling stats.Incr() without tags often), it can show up in benchmarks and guide
users toward this little cheat by passing in their tags in sorted order.

The `go vet` command in Go 1.16 reports a warning for inappropriate
use of reflect.StringHeader.

golang/go#40701

Its use in prometheus/metric.go to convert a byte array to a string in
place began to trigger the warning. That code has been replaced with a
safer variant that avoids the `vet` warning and still converts the array
without allocating new memory.

https://stackoverflow.com/a/66865482

Additionally, the CircleCI test now uses a pinned influxdb image of
1.8.9. The 2.x influxdb Docker images require authentication to use.

Co-authored-by: Collin Van Dyck <[email protected]>

The Datadog client now has the ability to send histogram metrics as the
Datadog-specific distribution metric type. The Datadog client
configuration has a new `DistributionPrefixes` item which specifies the
prefixes of metric names that, when reported as histograms to the stats
library, are to be sent as distributions instead. For example, when the
prefix list is set to `{ "dist_" }`, then any histogram metric whose
name begins with "dist_" is sent as a distribution; all other histograms
are sent as ordinary histograms, as before.

The default configuration sends no histograms as distributions.

This PR adds a first version of an OpenTelemetry handler. This handler
implement the otlp protocol with an HTTP Client.

There are few caveats with the current implementation:
- It only supports HTTP but GRPC should be easy enough to add later if needed.
- The client is written in a fire-and-forget fashion, meaning that metrics
will be sent once even if there is a failure when sending the request.
- The handler only support backends which expect cumulative values such as Prometheus.

…easure

… no semantic code changes

Co-authored-by: Kevin Burke <[email protected]>

It looks like functions had been renamed in some files but not others,
breaking tests for darwin
(though it's unclear why darwin tests are valuable for this package).

Add golang.org/x/exp/slices dependency.

This is allocation-free and has comparable speed to prior approach.
stdlib and slices package Sort functions
also use insertion sort for small inputs,
and as such a local insertion sort optimization
has not been needed since at least 1.18.

golang.org/x/exp/slices has comparable allocation-free sorting,
which we can use while reducing our code.

Neither Datadog nor Prometheus appear to retain or handle
multiple tags with the same name on the same metric,
so this package deduplicates at time of sort (latest tag wins).

If any metric systems we use do tolerate and provide useful behavior
when provided duplicate tag/label names, and the practice is justified,
that would be a reason to revert or adjust this deduplication behavior.

autofixed changes. no other updates

Co-authored-by: Kevin Burke <[email protected]>

* fix: upgrade the x/exp package, and updated tagIsLess function

* fix the test

* tagIsLess -> tagCompare

* revert dependency versions: attempt to fix subpackage failure

https://app.snyk.io/org/segment-pro/project/c9a18e75-de8c-4229-ad8d-2ca5c8f8cfbb/pr-check/15c5a32a-73c7-4cff-930d-39be988384cf

Vulnerable version of gopkg.in/yaml.v3 introduced through:

Introduced through: github.com/segmentio/[email protected] › github.com/segmentio/[email protected] › github.com/stretchr/[email protected] › github.com/stretchr/[email protected] › github.com/stretchr/[email protected] › gopkg.in/[email protected]

v1.0.3 of fasthash corrected a potential segfault issue.
segmentio/fasthash@9dc1b83

This is detectable using -race or -gcflags=all=-d=checkptr when running
code that imports this lib.

Co-authored-by: Dean Karn <[email protected]>

On tip (the Go 1.22 code freeze), Go reports that `compareTag` has the
wrong method signature:

```
type func(a Tag, b Tag) int of tagCompare does not match inferred type func(a Tag, b Tag) bool for func(a E, b E) bool
```

Fix this by using the correct method signature.

Builds are currently failing because something is running Node 16
which is no longer supported.

Previously they would fail with an anticipated error; instead, skip
the failing test on Darwin.

While the metrics are set in the correct order, the use of a HTTP
server to receive them means that the metrics can be received on the
server side in any order, which fails the tests 1 time out of 200,
potentially higher.

This means we can't rely on any ordering on the server side in the
test, and need to manually sort events.

Currently it just fails the main branch because it's not a requirement
of a passing build.

We turned on the linter to lint the "main" branch and any release
branches, but we never actually fixed any of the issues reported by
the linter. This is an attempt to do so. A lot of red herrings but
some legitimate errors.

Not strictly reported by the linter, but replace "syscall" uses with
"x/sys/unix", as is recommended.

Mostly it's complaining about x/net but take the opportunity to update
all dependencies.

Several Docker images used by Segment do not work reliably on Mac M1 laptops,
which use the ARM chipset. Commonly, these are images that were built several
years ago, before M1 laptops were in widespread use, and behave unpredictably
when run on an ARM chipset.

The simplest workaround is to ensure that the Docker environment is always
running on x86. This change should ensure that employees with M1 laptops will be
able to reliably start and run Docker containers on this repository.

…ic (#165)